The present invention relates generally to memory systems, and more particularly to an apparatus and method that can dynamically create an executable image from an object file stored in a reserved area of a data storage device of a memory system including a Redundant Array of Independent Disks (RAID) system.
Modern computer networks frequently require large, fault-tolerant memory systems. One approach to meeting this need is to provide a RAID system having a number of hard disk drives operated by a controller that is coupled to a host computer. RAID systems improve storage reliability, availability and system performance by providing storage capacities larger than any single data storage device. This larger storage capacity enables more data to be stored and accessed more rapidly. In addition, the larger storage capacity improves reliability by providing redundancy and allowing storage of parity and/or error checking bits.
RAID systems can be configured to store the data in numerous alternative ways commonly referred to as RAID levels. There are six basic RAID levels, each possessing different advantages and disadvantages. These levels are described in, for example, an article titled xe2x80x9cA Case for Redundant Arrays of Inexpensive Disks (RAID)xe2x80x9d by David A. Patterson, Garth Gibson and Randy H. Katz; University of California Report No. UCB/CSD 87/391, December 1987, which is incorporated herein by reference. RAID level 2 uses non-standard disks and as such is not normally commercially feasible.
RAID level 0 employs xe2x80x9cstripingxe2x80x9d, where the data is broken into a number of stripes which are stored across the disks in the array. This technique provides higher performance in accessing the data but provides no redundancy which is needed in the event of a disk failure.
RAID level 1 employs xe2x80x9cmirroringxe2x80x9d, where each unit of data is duplicated or xe2x80x9cmirroredxe2x80x9d onto another disk drive. Mirroring requires two or more disk drives. For read operations, this technique is advantageous since the read operations can be performed in parallel. A drawback with mirroring is that it achieves a storage efficiency of only 50%.
In RAID level 3, a data block is partitioned into stripes which are striped across a set of drives. A separate parity drive is used to store the parity bytes associated with the data block. The parity is used for data redundancy. Data can be regenerated when there is a single drive failure from the data on the remaining drives and the parity drive. This type of data management is advantageous since it requires less space than mirroring and only a single parity drive. In addition, the data is accessed in parallel from each drive which is beneficial for large file transfers. However, performance is poor for high input/output request (I/O) transaction applications since it requires access to each drive in the array.
In RAID level 4, an entire data block is written to a disk drive. Parity for each data block is stored on a single parity drive. Since each disk is accessed independently, this technique is beneficial for high I/O transaction applications. A drawback with this technique is the single parity disk which becomes a bottleneck since the single parity drive needs to be accessed for each write operation. This is especially burdensome when there are a number of small I/O operations scattered randomly across the disks in the array.
In RAID level 5, a data block is partitioned into stripes which are striped across the disk drives. Parity for the data blocks is distributed across the drives thereby reducing the bottleneck inherent to level 4 which stores the parity on a single disk drive. This technique offers fast throughput for small data files but performs poorly for large data files. Other somewhat non-standard RAID levels or configurations have been proposed and are in use. Some of these combine features of RAID configuration levels already described.
The controller provides the brains of the memory system, coordinating the operation of the disk drives to perform read and write functions, parity generation and checking, and handling drive failures without interrupting host requests. To provide this functionality utilizing minimal host processor time and without modifying user applications the controller typically includes a processor or Central Processing Unit (CPU), Random Access Memory (RAM) and a Programable Read Only Memory (PROM). In addition, the controller also includes firmware or microcode whose primary purpose is to initialize the memory system when it is first turned on. The process of initializing the memory system is commonly referred to as xe2x80x9cbootingxe2x80x9d, the system. Firmware is essentially a series of machine instructions stored in the PROM or other non-volatile memory. After power to the controller is turned on, the CPU begins to execute the firmware instructions and initialize the memory system. Thereafter, the controller functions to allow other operations to be performed, i.e., enables a host computer to write data to and read data from the memory system.
One problem or limitation encountered in the design of RAID systems concerns problems with the controller firmware. Basically, if the controller firmware has any program errors or if the components or configuration (RAID level) of the memory system needs to be changed, the firmware stored in the PROM must be upgraded, namely, replaced by another program without the problems or errors. Traditionally, this involved removing the existing PROM from the controller and replacing it with a new PROM pre-programmed with the corrected or upgraded programs. The latest generation of controllers uses Electronically Erasable PROM (EEPROM), also known as Flash EPROM, that along with utility programs on an attached host computer, allow the EEPROM to be erased and reprogrammed in-situ with new firmware downloaded via a host interface.
Significant problems remain, however, in that the above procedure typically requires that a user stop or shut down the controller prior to upgrading the firmware. This involves finishing or aborting all pending requests for data input/output, flushing the RAM, stopping background activities (such as Battery Back-up Unit monitoring, enclosure monitoring, and other periodic processes) and performing no host interrupts. After the firmware upgrade procedure, it is necessary to re-initialize the controller, sync up with a firmware power up procedure and, if needed due to a change in the configuration, to re-initialize and spin up disk drives in the array. These problems are multiplied if, as is often the case in larger computer networks, such as Wide Area Networks (WANs) and Local Area Networks (LANs), there are multiple RAID systems each coupled to a different host computer. In this situation the user must load or check to make certain that the firmware upgrade and the necessary utility programs are present on each host computer before beginning the upgrade procedure. Moreover, because the hardware and operating system on each RAID system and its associated host computer can vary due to differences in vendor, model or capacity, the user must check the upgrade to make certain the appropriate device drivers are present. This downtime can have a significant impact when the system is used, for example, in an information server, such as a server on the Internet running 24 hours a day and 7 days a week.
A more significant problem arises in those situations in which no interface between the controller of the RAID system and the host computer is possible. Inability to interface with the controller may be due to problems with the host computer, for example problems with the firmware in the RAID system may prevent loading an operating system for the host computer, or because the necessary utility program for erasing and reprogramming the EEPROM is not available on the host computer. The utility program can be unavailable because the host computer is a xe2x80x9cclosed systemxe2x80x9d, to which the user is unable or not authorized to load programs, or because the utility program conflicts with the operating system of the host computer.
Accordingly, there is a need for an apparatus and method for upgrading programs in a controller of a memory system without the use of a host computer and without requiring removal of the controller or any components thereof. It is desirable that the method work regardless of the configuration of the memory system and the vendor or model of the components thereof. It is also desirable that data stored in the array remain available to the host computer during the upgrading process.
The present invention provides a solution to these and other problems, and offers other advantages over the prior art.
The present invention relates to a method and apparatus for dynamically creating an executable image from an Object File Format (OFF) file, such as a Common Object File Format (COFF) or an Executable and Linking Format (ELF) file, stored in a reserved area of one of a number of data storage devices in memory system.
According to one embodiment, a controller is provided coupled to the storage devices. The controller has a Programable Read Only Memory (PROM) or equivalent programable memory in which an initial boot sequence is stored, a Random Access Memory (RAM) in which the executable image is assembled and a Central Processing Unit (CPU) or other processor capable of performing a hardware discovery sequence, reading data from the OFF file, assembling the executable image in RAM and executing the executable image. Generally, the PROM further includes a computer program that enables the CPU to translate the data from the OFF file into the executable image. In one embodiment, the PROM is an Electronically Erasable PROM (EEPROM), the executable image is a firmware boot image, and the CPU is capable of erasing the initial boot sequence from the EEPROM and storing the assembled executable image in the EEPROM. In another embodiment, the data storage devices are disk drives in a Redundant Array of Independent Disks (RAID) system, and the OFF file is provided by replacing a hot spare disk drive with an upgrade disk drive having a reserved area with the OFF file stored therein. The memory system of the present invention is particularly advantageous for use in computer networks having a host computer capable of writing data to and reading data from the memory system and a bus coupling the host computer to the controller of the memory system. While the invention provides significant advantages for RAID type devices, it will be appreciated that the method and the device may be broadly applied to dynamic firmware image creation generally and is not limited to such memory storage systems environments or applications.
In another aspect, the present invention is directed to a method of operating a memory system to create an executable image from data in an OFF file. In the method, at least one of a number of data storage devices is provided with a reserved area having the OFF file stored therein. A controller is coupled to the data storage devices, the controller having a PROM, a RAM and a CPU. The memory system is initialized, data read from the OFF file to create the executable image and the executable image assembled in RAM. Typically, the PROM has an initial boot sequence is stored therein, and the step of initializing the memory system involves the CPU executing the initial boot sequence. Preferably, initializing the memory system includes performing a hardware discovery sequence on the memory system, and the step of reading data from the OFF file involves reading data related to hardware discovered. Optionally, when the data storage devices are disk drives in a RAID system, the step of initializing the memory system also includes the step of discovering the configuration or RAID level of the RAID system. In one embodiment, the PROM further includes computer programs that enable the CPU to translate the data stored in the OFF file from an object format into an executable format compatible with the PROM and to link the data to assemble an executable image, and the step of creating an executable image includes the steps of translating data read from the OFF file and linking the data to assemble the executable image. In another embodiment, the PROM is an Electronically Erasable PROM (EEPROM), and the method includes the further steps of erasing the initial boot sequence from the EEPROM, and storing the assembled executable image in the EEPROM. Frequently, data storage devices are disk drives in a RAID system, and the step of providing a disk drive having a reserved area with the OFF file stored therein involves replacing a hot spare disk drive in the RAID system with an upgrade disk drive having the reserved area. The method may desirably further includes the step of removing the upgrade disk drive with the reserved area and replacing the hot spare disk drive when creation of the executable image is complete.
In yet another aspect, the present invention is directed to a memory system having means for creating an executable firmware image and storing the executable firmware image in the PROM, thereby replacing the initial boot sequence. As in the embodiments described above, the data storage devices include at least one data storage device having a reserved area with an OFF file stored therein, and the means for creating an executable firmware image includes a computer program that enables the CPU to translate the data stored in the OFF file from an object format into an executable format compatible with the PROM and assemble the executable firmware image in RAM. Preferably, the data storage devices are disk drives in a RAID system, and the data storage device having the reserved area is an upgrade disk drive installed in place of a hot spare disk drive in the RAID system.
In still another aspect, the present invention is directed to a computer program product for use in conjunction with a computer system. The computer program product includes a computer readable storage medium having a computer program mechanism embedded therein. The computer program mechanism includes a program module that directs a controller having a Programable Read Only Memory (PROM), Random Access Memory (RAM) and a Central Processing Unit (CPU), to create an executable image from data in an Object File Format (OFF) file stored in a reserved area of one of a plurality of data storage devices. The program module includes program code or instructions for: (i) coupling the controller to the plurality of data storage devices; (ii) initializing the controller; (iii) reading data from the OFF file; and (iv) assembling the executable image in RAM.